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FOREWORD 

The  Defense  Communications  Engineering  Center  (DCEC)  Technical  Notes(TN's) 
are  published  to  inform  interested  members  of  the  defense  community  regarding 
technical  activities  of  the  Center,  completed  and  in  progress.  They  are 
intended  to  stimulate  thinking  and  encourage  information  exchange;  but  they 
do  not  represent  an  approved  position  or  policy  of  DCEC,  and  should  not  be 
used  as  authoritative  guidance  for  related  planning  and/or  further  action. 

Comments  or  technical  inquiries  concerning  this  document  are  welcome, 
and  should  be  directed  to: 
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I.  INTRODUCTION 


1 . PURPOSE 

The  Military  Departments  and  Defense  Agencies  are  currently  planning 
and  implementing  a wide  variety  of  automatic  data  processing  (ADP)  systems 
to  increase  the  effectiveness  with  which  they  accomplish  their  assigned 
missions.  The  purpose  of  this  report  is  to  take  a preliminary  look  at 
these  evolving  ADP  systems  as  a point  of  departure  for  a continuing  effort 
within  DCEC  to  evaluate  the  potential  impact  of  DoD  information  transfer 
needs  on  the  future  DCS.  The  functional  and  statistical  aspects  of  the 
common  unit  of  information  transfer,  the  TRANSACTION,  are  discussed, 
together  with  the  relative  distributions  which  may  be  anticipated  for  the 
various  categories  of  transactions.  A projection  of  the  traffic  that 
could  be  imposed  on  the  DCS  during  the  1980-86  time  frame  as  a result  of 
the  implementation  of  these  systems  is  also  addressed. 

2.  DEFINITIONS 

a.  User  Requirements.  For  the  purpose  of  this  report,  user  requirements 
are  defined  as  those  teleprocessing  needs  which  reflect  the  basic  ADP  system 
design  objectives,  and  are  formulated  from  the  ADP  system  designers'  point 

of  view.  "User"  requirements  are  held  distinct  from  "system"  requirements 
in  that  "system"  requirements  are  generally  derived  from  "user"  requirements 
and  are  primarily  concerned  with  the  network  aspects  of  sizing,  switch 
placement,  and  other  matters  pertaining  to  satisfactory  communications 
service,  and  are  normally  not  visible  to  the  user. 

b.  Functional /Statist! cal  Requirements.  User  requirements  are 
further  specified  in  terms  of  their  functional  and  statistical  aspects. 
Functional  requirements  are  not  specifically  parameter  related,  but  are 
descriptive  of  a generic  class  or  type  of  capability  such  as  the  need  for 
speed  conversion,  mail  box  service,  etc.  Statistical  requrements,  on  the 
other  hand,  are  those  requirements  which  can  only  be  accurately  and 
completely  described  by  the  specification  of  a parameter  value  or  distribution. 
It  is  the  statistical  aspect  of  the  user  requirements  with  which  this  report 
is  primarily  concerned. 

c.  User  Requirement  Time  Periods.  User  requirements  are  divided  into 
the  following  three  time  periods  to  reflect  more  clearly  time-related 
considerations: 

• Near  Term  (1977-1980)  - specific  "Validated"  reouirements 
expressed  in  a high  degree  of  detail. 

• Mid  Term  (1981-1986)  - projected  requirements  beyond  the 
validation  phase  that  need  a relatively  high  degree  of  detail 
to  support  current  network  design  efforts. 


• Far  Term  (1987  and  beyond)  - qualitative  requirement  identi- 
fication and  gross  quantity  projections  in  support  of  transi- 
tion and  other  broad  issues  concerned  with  future  program 
direction. 

3.  THE  NATURE  OF  THE  EVOLVING  "DmIA"  TRANSFER  ENVIRONMENT 

a.  The  Current  Situation.  Past  studies,  in  particular  the  "DoD  ADP 
Systems  and  the  DCS"  (1)  , Volumes  I and  III  of  the  DCS  Plan  FY  76/86 
and  the  DoD  "Data  Internet  Study"  (3),  have  indicated  the  rapidly  growing 
need  for  a DCS  switched  communications  service  that  is  more  responsive  than 
the  present  DCS  switched  networks  to  ADP  and  ADP  related  communications 
needs.  Over  150  ADP  systems  throughout  the  DoD  with  implementation  schedules 
between  now  and  1980  have  been  identified  in  these  studies.  Initial  review 
of  the  associated  communications  requirements  indicates  that  the  needs  of 
only  56  can  be  fully  satisfied  by  the  current  AUTODIN  network  (AUTODIN  I). 

An  additional  78  systems  were  identified  as  candidates  for  a "common  user" 
type  service,  but  could  not  be  effectively  supported  by  the  current  network 
because  of  limitations  in  three  principal  aspects:  (1)  speed  of  service, 

(2)  transfer  protocols,  and  (3)  unit  transfer  lengths.  The  communications 
needs  of  these  systems  are  currently  being  addressed  in  the  AUTODIN  II, 

Phase  1 program.  The  DCS  role  in  supporting  the  communications  needs  of 
the  balance  of  the  systems  identified  has  not  yet  been  fully  evaluated 
and  is  being  investigated  by  DCEC  in  support  of  the  current  DTACCS 
directed  Integrated  AUTODIN  System  (IAS)  Program. 

b.  The  Emerging  Situation.  In  addition  to  the  traditional  areas  of 
command  and  control,  intelligence  gathering,  logistics,  and  personnel 
management,  emerging  information  processing  systems  are  finding  application 
in  a wide  variety  of  situations  requiring  the  rapid  assimilation  and/or 
processing  of  information  affecting  many  other  aspects  of  defense  management. 
As  technology  changes,  so  do  the  concepts  by  which  we  understand  the 
content  of  information  and  the  need  for  its  transfer  from  one  point  to 
another.  For  many  systems,  computer  and  terminal  facilities  are  being 
located  at  widely  dispersed  geographic  points,  and  therefore  large  volumes 

of  information  must  be  transferred  between  these  facilities.  In  addition, 
a need  is  rapidly  emerging  in  response  to  the  evolving  complexities  of  our 
operations  to  exchange  information  between  traditionally  isolated  systems 
on  a more  or  less  routine  basis.  That  these  evolving  information  pro- 
cessing systems  will  have  a considerable  impact  upon  the  nature  and  extent 
of  future  DoD  communications  network  design  is  clearly  evident. 

4.  THE  IMPORTANCE  OF  USER  REQUIREMENT  IDENTIFICATION 

Because  of  the  foregoing  considerations,  DCEC  is  currently  engaged 
in  various  programs,  particularly  the  AUTODIN  II  and  IAS,  intended  to 
meet  the  data  transfer  needs  of  the  identified  future  users  of  the  DCS 
in  a cost-effective  manner.  The  most  essential  of  these  planning  efforts, 
and  the  most  difficult  to  perform,  is  the  identification  of  the  specific 
user  needs  which  the  communications  network  will  be  called  upon  to  support. 
The  remainder  of  this  report  attempts  to  provide  some  insight  into  the 
nature  of  these  needs. 
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II.  INFORMATION  TRANSFER  NEEDS 


1.  PRESENT  NEEDS  (1977-1980) 

a.  Definition  of  Present  Needs.  For  the  purpose  of  this  report, 
present  needs  are  represented  by  th¥^  validated  subscriber  listing  sub- 
mitted by  the  Military  Departments  for  the  AUTODIN  II  program,  the 
requirements  exhibited  by  the  current  AUTODIN  community,  and  the  findings 
derived  from  the  previous  study  by  DCEO(l).  Questionnaires  were  developed 
to  obtain  the  specific  information  from  the  Military  Departments  required 
to  analyze  the  communications  requirements  of  each  validated  ADP  system. 
Detailed  information  about  each  system,  such  as  equipment,  geographic 
locations,  projected  traffic  volumes,  and  transaction  classifications,  was 
requested.  This  information  was  then  augmented  by  personal  contact  with  ADP 
personnel  associated  with  the  ADP  systems  under  review. 

b.  Requirement  Trends.  Two  related  trends  found  to  be  developing 
within  the  DoD  community  will  have  considerable  impact  on  the  near-term 
DCS: 

• The  advantages  of  consolidating  ADP  and  telecommunications 
planning  is  gaining  wider  recognition  within  the  DoD  manage- 
ment structure. 

• The  economies  which  can  be  achieved  through  automation  in  the 
various  areas  of  traditional  management  functions  are  giving 
new  impetus  to  the  development  of  complex  management  informa- 
tion processing  systems. 

c.  The  Increasing  Complexity  of  Demand.  While  there  is  a trend 
toward  consolidated  "teleprocessing"  planning,  the  vastly  greater  accumu- 
lations of  information  made  possible  by  the  available  technology  is  creating 
a current  demand  for  a more  sophisticated  communications  network  than  that 
presently  available  within  the  "store-and-forward"  environment.  This  sophis- 
tication of  communications  demand  arises  from  several  factors: 

• ADP  systems  are  no  longer  being  implemented  in  isolation  of  one 
another  but  are  being  consolidated  and  interconnected  within  a 
complex  arrangement  such  as  that  partially  depicted  in  Figure  1 
for  currently  identified  Air  Force  Systems. 

• Rapid  response  times  nornally  associated  with  priority  matters 
affecting  the  national  security  are  now  required  on  a regular 
basis  for  matters  affecting  management  efficiency.  In  particular, 
the  philosophy  of  the  new  management  information  systems  is  to 
record  information  into  computer  format  for  electrical  trans- 
mission at  the  information  source,  thereby  avoiding  duplication 

in  effort  and  time  lags  inherent  in  the  more  conventional  acquisi- 
tion of  information. 


3 


to 
0)  • 

36  0 

0 

0 

a.  1 

r- 

c E 
to  0 

1 

to 

Z 4J 

0 

to 

z 

"O  >0 
c in 
to 

tJ 

E to 

E 4-> 

Xf  t- 
c ^ 
to  4<» 
c 

O QJ  O 
* a»  c o ll. 
o •»-  < 

W 4->  Oi  u. 

' o c u < 

U.  3 C 
O >0 

u o c 

•r-  O ‘r- 
/<  < LU 


*0  01  t/) 

01  C _ Q 
O C £ Q. 
C O 0)  < 
<0  </>  4^ 

> (>  M 
■O  0>  >> 
<0.00 


•U  6 Z 
«0  4->  0»  i-i 
I-  C 4^  S 
•M  0)  to  Q 
to  E*>>< 

•r-  <y  (/> 

C C7> 

•t~  to  ez 
ECO 

*o  #0  •»- 
< z +-> 


r to 
to  f 
•o  c 
c a. 

<0  E 
4J  -g  o 
VO  < 00 

>»  4^  •-• 

S.  u S 
to  fO 
+»  t.  . 

Bt  \ 

z o 


to 

u 

O) 

o 

E 

c O VO 
-O’  o 

40 

o >>  o 
to  to 
c 

0>  <0 


to 

*o  s 
«a  c fo 

4->  to  1. 
to  4->  0> 

O VO  o ^ 

u c 

r-  C Ci-  CO 

o;  o o 
> T-  C ^ 
(U  4-»  o CO 

•J  to  ’r- 
E 4^ 

0)  o <o 

to  4-»  M 

to  3 'f- 

CO  eX  *0 


•o  u 

0J‘»-  VO 
U4-»  £ ^ 

c tn  o)  < 
to*#-  4-» 

> cn  to 
:oo  >» 

<— I VO 


3 X-  h- 

«x  r-  o <j: 

•o  2 VO 

O ■!-»  4J 

< o 0> 
to  »—  z 


■ 


>t  E 

c i-  0) 

O trs  •M 

>1-  i/l 

4J  r-  >» 

I-  r-  VO 
O 

o.  s •- 

X. 

. 0>  0>  4-t  U. 
U -O  C «X 
V.  •#-  O I 
o :t  VO 
u;  *o  *0  o 
o 

^ *0  £ 


01 

•o  C to 

•r-  o 4-» 

s •#-  to  E 

•o  4^  O Oi 

VO  ^ i-  4J 
Z X-  O <D  to  Lu 

O Q.  U >^  < 

*—13:^  C VO  I I 

o a>  VO 
u CO  cn  X 
^ S-  »r-  C Q 

O' r-  H-. 

U-  f—  r— 

^ o>  *0 

I-  4J  c 

•#-  C fTJ 

«t  t~»  X 


L. 

<x  «o 

E 

V-  *0 

Of 

0 c 

4-»  to 

•0 

to  0 

5 

>0  <-> 

c E 

VO  u. 

Of  0 

< 

E 0 

f—  0 

0 

X.  a» 

X. 

(O  v> 

4-> 

Q.  X. 

c 

at  0 

0 

0 u. 

0 

•o 
01  E 

4->4->  O 
*4-  JO  4-> 

•r>  V.  (/) 
f—  O)  >i 

L 0>  CO 
••-+J  VO 

< C 4J  S 

t— * c 
>>  00 

X.-0  E C 

to  c 01  Z 

, 44  fO  CO 
E to 
•—EC 
•I-  o to 

so  s 


Figure  1.  A Partial  Depiction  of  ADP  System  Functional  Interaction  In  the  Air  Force 


• The  extent  of  the  problems  related  to  the  new  information  handling 
systems  is  resulting  in  a substantial  increase  in  the  requirement 
for  bulk  data  transfer  with  associated  handling  efficiencies  which 
cannot  be  achieved  within  the  existing  switched  networks. 
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• Various  DoD  elements  are  currently  implementing  both  time  sharing 
systems  and  data  sharing  systems,  such  as  the  Air  Force  CREATE  and 
LITE  systems,  which  tend  to  create  large  central  information  de- 
positories for  use  by  widely  dispersed  users.  It  is  anticipated 
that  these  types  of  systems  will  continue  to  spread  and  will  con- 
stitute a substantial  percentage  of  the  future  DoD  data  communica- 
tions requirement.  To  this  end,  several  ADP  systems  were  identi- 
fied during  the  course  of  recent  surveys  (Data  Internet  Study, 
AUTODIN  II  Requirements  review,  etc.)  for  which  no  current  data  com- 
munications requirements  were  identified  but  which  nevertheless 
. appear  to  have  potential  as  time  sharing  or  data  sharing  systems 
within  the  very  near  future. 

2.  FUTURE  NEEDS  (1981-1990) 

a.  Requirement  Evaluation.  In  an  attempt  to  forecast  data  transfer 
needs  for  the  post-1980  time  frame,  several  previous  sources,  notably 
reference  [2]  and  [3],  together  with  ARPA  and  AUTODIN  traffic  statistics, 
were  evaluated.  Information  subsequently  obtained  from  the  Military 
Departments  in  support  of  the  AUTODIN  II  effort  was  also  considered,  but 
found  to  be  primarily  addressed  to  existing  ADP  systems  or  those  in  an 
advanced  planning  stage  with  funds  allocated.  The  available  information 
did  not  address  requirements  which  are  still  on  the  "drawing  board"  or 
have  not  as  yet  filtered  down  to  the  "communications"  community.  Thus, 
the  information  obtained  provides  a fairly  accurate  overview  of  the  near- 
term  (1976-80)  data  requirements  but  provides  little  insight  into  the 
specific  nature  of  data  requirements  beyond  this  time  period.  For  this 
reason,  a thorough  search  of  the  available  literature  was  made  in  the  hope 
of  acquiring  a more  definitive  insight  into  where  data  transfer  require- 
ments may  be  heading  in  the  1981-86  time  period.  The  balance  of  this 
report  is  addressed  to  the  findings  of  this  search,  and  to  a discussion 
of  how  these  findings  have  been  incorporated  into  a statistical  character- 
ization of  the  data  transfer  needs  to  be  supported  by  the  1981-86  DCS, 

b.  Pertinent  Observations  From  the  Literature.  Several  sources  pro- 
vide a valuable  insight  into  the  direction  that  information  transfer 
needs  may  take  in  the  1981-1986  time  frame  and  beyond.  Notable  of  these 
are  ESD's  "Mission  Analysis  on  Air  Force  Base  Communications-1985"  [4], 
and  two  of  James  Martin's  books  - "Future  Developments  in  Telecommunica- 
tions" [5]  , and  "The  Computerized  Society"  [6].  From  these  works  and 
the  literature  in  general,  seven  important  points  emerge: 

0 The  present  communications  network  does  not  completely 
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satisfy  today's  needs  to  transfer  information.  Accordingly, 
the  way  the  communications  user  conducts  his  day-to-day 
business  is  heavily  biased  by  the  existing  communications 
facilities  available  to  him. 

• Teleprocessing  acquisitions  and  programs  have  responded  to 
identified  deficiencies  in  specific  user  areas  rather  than 
addressing  the  total  information  creation,  transfer,  storage 
and  retrieval  problem.  Accordingly,  a detailed  listing  of 
user  identified  deficiencies,  with  associated  validated  com- 
munications requirements,  is  not  a sufficient  basis  from  which 

to  evaluate  the  adequacy  of  today's  information  transfer  systems. 

• The  normal  tendancy  on  the  part  of  the  network  designer  to 
push  for  a "standardized"  family  of  user  terminal  devices  in 

• order  to  minimize  network  design  problems  may  offset  the  less 
obvious  but  equally  important  economic  benefits  and  technolo- 
gical innovations  which  will  accrue  to  the  customer  in  an 
"open"  terminal  market.  This  is  not  to  say,  however,  that 
certain  operating  features  or  interface  characteristics  should 
not  be  standardized  when  standardization  clearly  benefits  both 
the  ADP  and  communications  systems  designers. 

• Available  information,  such  as  the  Air  Force  Base  Mission 
Analysis  summarized  in  Table  I,  indicates  that  current  "data 
network"  traffic  (electrical  message,  data,  and  graphics) 
now  supports  less  than  6%  of  the  total  Air  Force  information 
transfer  need.  Providing  users  with  a totally  responsive, 
integrated  information  transfer  network  will  set  the  stage 
for  a sudden,  massive  spread  in  data  communications  usage  into 
functional  areas  which  have  traditionally  been  accomplished 
either  by  nonelectrical  transfer  cr  less  efficiently  by  telephone. 

• With  the  increasing  complexity  of  DoD  management  decisions, 
as  well  as  those  of  government  and  the  business  community 
as  a whole,  the  need  for  collecting  vast  quantities  of  data 
to  support  complex  resource  management  allocations  and 
decisions  is  becoming  more  and  more  essential  to  orderly 
government  operation.  Accordingly,  there  will  be  a considerable 
increase  in  the  volume  as  well  as  type  of  traffic  handled  by 
the  data  communications  networks  of  the  future. 

• In  projecting  future  requirements,  overconservatism  usually 
prevails.  The  literature  is  replete  with  exdmpl':s  of  in- 
sufficient imagination  resulting  in  a failure  t.>  foresee 
major  applications  and  has  led  to  the  under-design  of  many 
systems.  Although  examples  to  the  contrary,  such  as  the 
"picturephone,"  are  recognized,  these  are  the  exceptions 
rather  than  the  rule. 
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normalized  unit  of  measurement  for  all  type  information  transfer  actions. 


• It  has  been  found  that  newly  developed  technology  generally 
precedes  implementation  by  5 to  10  years  due  primarily  to 
application  engineering  and  program  inertia.  Therefore,  the 
impact  of  currently  emerging  technological  advances  upon  the 
communications  networks  will  not  be  generally  felt  until  the 
post-1986  time  period  and  will  not  impact  the  interim  data 
networks.  For  this  reason,  the  user  needs  forecasted  in  this 
report  are  based  solely  on  the  technology  now  in  being. 

c.  A Forecast  of  Teleprocessing  Needs  (1981-1990).  The  following 
discussion  highlights  some  of  the  changes  which  will  most  likely  occur 
to  teleprocessing  during  the  next  10  to  15  years: 

• The  requirement  to  move  more  information  in  a shorter  time 
span  will  be  reflected  in  greatly  enhanced  efforts  to  automate 

• source  data  entry  at  the  communications  terminal  with  direct 
voice/data  input  offering  the  greatest  system  improvement. 

t To  reduce  access  line  costs,  the  primary  interface  between  the 
user  and  the  long-haul  communications  network  at  least  for  major 
military  installations,  will  be  a large  base  concentrator(s) . 
These  concentrators  will  provide  a significant  improvement  over 
those  currently  available  in  providing  true  "ust r-to-user," 
multi-media  communications  service. 

$ The  separate  functional  areas  of  communications,  data  auto- 
mation, and  resource  management  will  be  merged  into  one  area 
treating  information  creation,  processing,  and  resource  manage- 
ment transfer  as  an  integrated  whole. 


Developments  in  large  scale  integrated  circuits  and  plasma 
display  technologies  offer  considerable  potential  for  new 
teleprocessing  applications. 

Routine  clerical  functions  such  as  file  updating,  text  correcting, 
dictation,  etc.,  will  be  performed  on  a routine  basis  by  the 
teleprocessing  system  - often  from  a location  remote  from  the 
Central  File. 


The  fact  that  personnel  costs  constitute  the  bulk  of  the 
annual  increment  of  life  cycle  costs  for  administrative  type 
services  will  be  the  major  driving  force  for  conversion  to 
ADP  operation. 

Multiple  copies  of  manuals  and  other  bulky  documentation  will 
be  reduced  to  a single  control  file  with  electrical  access 
and  peripheral  reproduction  capability.  The  transfer  of  the 
large  volumes  of  data  associated  with  this  concept  will  be 
facilitated  by  the  increased  bandwidth  available  for  bulk 
data  transfer  and  the  application  of  "slow  scan"  techniques 
together  with  "cheap"  terminal  storage. 


• In  order  to  increase  both  employee  and  management  productivity, 
more  and  more  personnel  will  have  communications  terminals  at 
their  desks. 

• With  the  increasing  deterioration  of  mail  service  as  volume 
grows  and  transportation  and  handling  costs  increase,  facsimile 
"mail"  will  likely  become  a much  more  attractive  alternative  to 
current  operations  and  will  place  a substantial  demand  on  the 
future  DCS. 

t With  the  availability  of  larger  ba’‘,dwidths,  facsimile  may  be 
coupled  directly  to  the  office  copiers  and  operated  at  com- 
patible speeds. 

• The  use  of  the  Touchtone  telephone  as  a cheap  computer 
terminal  with  voice  answerback  or  a coupled  digital  display, 
will  greatly  expand  teleprocessing  applications. 

• Optical  processors  will  greatly  enhance  pattern  recognition, 
associative  processing,  and  other  areas  in  which  a very  large 
number  of  different  data  elements  must  be  correlated,  again 
creating  new  applications  for  data  transfer. 

I Work  patterns  will  change  as  screen-to-screen  communications 
proves  to  be  an  attractive  alternative  to  business  travel. 

This  application  will  be  greatly  enhanced  by  the  addition  of 
facsimile  peripherals  for  the  transmission  of  permanent  copies 
of  notes,  sketches,  or  other  "briefing"  type  material,  and, 
in  particular,  preliminary  drafts  of  planning  documents  at  a 
much  earlier  stage  of  development  then  now  thought  practical. 

• There  will  be  many  areas  of  software  standardization  that 

will  have  a snowball  effect  as  programs  used  in  one  installation 
spread  to  others. 


t Extremely  large  computer  files  (data  banks)  will  be  available 
in  which  every  item  stored  can  be  retrieved  in  a fraction  of  a 
second.  Banks  of  data  on  many  subjects  will  grow  to  the 
extent  that  computers  will  be  used  as  "librarians"  for  aiding 
in  the  worldwide  search  for  particular  items  of  information. 

* 

• Data  transmission  will  drop  in  cost.  Long  distance  costs  will 
drop  much  more  than  short-distance  costs,  thereby  having  an 
t effect  on  the  organizational  structure  of  the  various  depart- 

ments and  agencies  of  the  Federal  Government.  Computers  will 
also  drop  in  costs  at  a faster  rate  than  communications  lines. 

To  some  extent  this  trend  will  counter  the  trend  towards  in- 
creased use  of  data  transmission  (i.e.,  greater  decentralization). 
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• The  processing  of  "tactical"  information  in  support  of  real- 
time mission  objectives  will  be  removed  from  the  forward  area 
of  the  battlefield  to  reflect  the  growing  complexities  of  fire 
control  and  target  assignment  systems  and  their  integration 
across  organizational  and  joint  service  lines.  This  may  well 
involve  the  DCS  as  a necessary  link  in  the  normal  tactical-to- 
tactical  data  information  flow. 

d.  System  Management  Needs.  In  addition  to  user  information  transfer 
needs,  there  is  also  a continuing  need  by  both  the  ADP  system  and  the  com- 
munications network  managers  to  know  how  effectively  the  information  trans- 
fer has  been  accomplished.  Teleprocessing  systems  have  evolved  from  a 
conglomeration  of  terminal  types  and  communications  subsystems  carrying 
all  manner  of  traffic  including  teletype,  high  and  low  speed  data,  fac- 
simile, analog  and  digital  voice,  and  video.  To  be  effective  and  efficient 
at  this’level  of  complexity,  all  functional  entities  at  all  echelons  of 
the  network  configuration  must  be  considered  as  a single  interacting  body 
for  the  purpose  of  transferring  information  between  users  to  their  mutual 
satisfaction.  Successful  accomplishment  of  this  mission  can  only  be 
measured  in  terms  related  to  the  total  body  --  not  merely  according  to 
how  well  any  particular  communications  subsystem  may  operate. 

In  contemporary  teleprocessing  systems  the  first  indication  of  mal- 
function or  failure  is  often  the  user's  inability  to  communicate,  even 
though  the  failure  may  have  occurred  much  earlier.  The  managers  of 
future  teleprocessing  systems  will  require  continuous  automatic  monitoring 
of  all  communications  facilities  along  the  lines  currently  being  planned 
for  the  DCA  System  Control  and  Management  Information  System,  so  that 
corrective  actions  can  be  taken  before  major  failure  occurs. 

The  teleprocessing  managers  will  require  specific  statistical  infor- 
mation from  the  communications  network,  together  with  a system  to  process, 
interpret,  and  evaluate  this  information,  and  to  relay  the  findings  to 
the  proper  authorities  for  system  management  and  system  control. 
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III.  INFORMATION  TRANSFER  REQUIREMENT  CHARACTERIZATION 


1.  OVERVIEW 

a.  Requirement  Characterization  Perspective.  In  our  present 
record  communications  environment  as  typified  by  AUTODIN  I,  information 
transfer  requirements  are  generally  reported  in  terms  of  average  "mes- 
sage" lengths  and  busy  hour  load  on  the  network.  For  the  most  part, 
these  figures  are  obtained  on  a "circuit"  basis  rather  than  for  a parti- 
cular user  or  ADP  system,  except  where  the  user  has  his  own  terminal  and 
does  not  rely  on  a communications  center  for  input  into  the  communica- 
tions network.  Lacking  any  significant  insight  into  what  forces  this 
traffic,  user  requirement  projections  have  not  adequately  foreseen 

major  changes  in  the  traffic  demands  resulting  from  contingency  operations 
ojr  from  major  changes  in  the  way  the  user  does  business.  This  picture  is 
now  changing  as  the  major  percentage  of  total  data  traffic  swings  from 
the  traditional  narrative/record  category  to  traffic  generated  within  a 
well-defined  ADP  system,  for  which  records  are  generally  maintained  on  a 
transaction-by-transaction  basis  in  response  to  ADP  system  management 
needs  and  as  a byproduct  of  the  ADP  system  capability.  As  yet  very 
little  information  of  this  nature  has  been  made  available  to  DCEC, 
except  for  the  more  "traditional"  data  networks  identified  for  AUTODIN  II. 
To  overcome  these  deficiencies,  DCEC  is  currently  developing  a definitive 
user  requirement  model  for  the  DCS  which  will  incorporate  newly  emerging 
transactional  statistics,  together  with  the  relationships  which  may 
exist  between  these  statistics  and  certain  definable  force  parameters 
such  as  troop  population,  number  of  aircraft,  mission  objectives,  etc. 
However,  this  effort  is  not  expected  to  produce  definitive  results 
until  the  middle  of  calendar  year  1978. 

b.  The  Current  Information  Transfer  Requirement  Baseline.  Pending 
completion  of  the  DCS  User  Requirement  Model,  guidelines  are  required 
concerning  future  user  requirement  demand  on  the  DCS  to  support  the 
ongoing  planning  efforts  within  DCEC  and  Headquarters  DCA.  This  interim 
need  is  addressed  by  using  the  traditional  "average"  or  "typical"  trans- 
actional attributes,  but  adding  as  much  insight  as  currently  available 
information  and  a few  educated  guesses  will  allow. 

First,  the  requirement  to  transfer  information  is  separated  into 
five  general  application  categories  for  ease  of  further  discussion. 

The  relative  frequency  of  transactions  in  each  category  together  with 
the  primary  transactional  attributes-response  time  and  transaction 
length-are  investigated.  The  results  of  this  investigation  are  then 
coupled  with  an  estimate  of  total  network  traffic  demand  envisioned 
for  the  1981-86  time  frame  to  derive  daily  and  busy  hour  traffic  pro- 
jections for  each  application  category.  Finally,  a few  observations 
on  the  user's  requirement  to  transfer  information  are  presented  where 
trends  indicate  the  possible  need  to  change  traditional  thinking. 
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2.  APPLICATION  CATEGORIES 


Teleprocessing  systems  are  established  for  a wide  variety  of  purposes 
and  differ  according  to  the  demand  they  place  upon  the  cormunications 
network.  To  facilitate  system  design,  the  wide  variety  of  applications 
should  be  ordered  into  as  few  categories  as  possible,  still  retaining 
the  basic  attributes  of  the  service  requirement.  Ideally,  these  cate- 
gories would  be  uniquely  defined,  both  in  terms  of  ADP  function  and  in 
terms  of  the  basic  transaction  parameters  of  response  time  and  trans- 
action length.  Unfortunately,  it  is  found  that  the  relationships  between 
function,  response  time,  and  transaction  length  are  not  consistent  across 
the  spectrum  of  data  applications.  Accordingly,  each  application  cate- 
gory is  defined  primarily  by  its  most  descriptive  attribute,  with  the 
other  attributes  assigned  appropriate  boundary  values  which  may  sometimes 
overlap  adjacent  categories.  As  an  example,  the  BULK  1 application 
category  is  defined  primarily  in  terms  of  its  function  of  transmitting 
entire  data  files  or  computer  programs,  and  secondarily  in  terms  of  a 
response  time  requi remen tgOf  less  than  1 hour  and  by  transaction  lengths 
normally  not  exceeding  10°  bits.  However,  certain  BULK  1 type  trans- 
actions (requiring  response  times  less  than  1 hour)  can  be  of  a length 
greater  than  10°  bits  - thereby  impinging  on  the  BULK  2 domain;  or  they 
may  have  response  time  requirements  of  less  than  5 minutes  - thereby 
impinging  on  the  INQUIRY/RESPONSE  domain.  For  reference,  these  cate- 
gories are  defined  in  the  following  subsections  in  terms  of  their  func- 
tional attributes  and  graphically  depicted  in  terms  of  their  primary 
transactional  parameters  in  Figure  2.  The  order  of  importance  placed  on 
the  transaction  attributes  in  defining  each  application  category  is 
summarized  in  Table  II. 

a.  Interactive.  These  are  applications  requiring  an  immediate  o»“ 
"real  time"  response.  This  category  is  further  divided  functionally 
into  the  following  three  subcategories: 


• Human  Interaction.  Those  applications  where  a human-computer 
or  human-human  dialogue  takes  place  and  responses  must  be 
quick  enough  not  to  impede  the  operator's  train  o'  thought. 

• Alarm/Status  Indicators.  Those  applications  where  a transmitted 
remote  alarm  or  status  indication  requires  a "real-time"  response 
either  from  a machine  or  from  a human  operator.  For  ease  of 
classification,  this  category  is  differentiated  from  monitoring/ 
telemetry  by  defining  transaction  length  to  not  exceed  10  bits 

or  one  character  of  information  text. 


Monitoring/Telemetry.  These  are  applications  where  remote  tele- 
metry  or  other  monitoring  information  is  transmitted  which  requires 
"real  time"  data  reduction  or  graphic  display  at  some  central  con- 
trol point. 
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Delivery  Time  or  Response  Time  ( seconds) 
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TABLE  II.  ORDER  OF  IMPORTANCE  OF  TRANSACTION  ATTRIBUTES  IN  DEFINING 
APPLICATION  CATEGORY. 


. APPLICATION  CATEGORY 

FUNCTIONAL 

DESCRIPTIONS 

RESPONSE 

TIME 

TRANSACTION 

LENGTH 

INTERACTIVE 

Human  Interaction 

2 

1 

Alarms/Status  Indicators 

2 

1 

2 

Mon i tori ng/Tel emetry 

2 

1 

3 

INQUIRY/RESPONSE 

1 

2 

3 

NARRATIVE/RECORD 

1 

3 

3 

BULK  1 

1 

2 

3 

BULK  2 

3 

1 

2 
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b.  Inquiry/Response.  These  are  applications  where  short  requests 

or  inquiries  are  made  of  a central  data  bank,  and  responses  of  from  5 to  10 
minutes  do  not  cause  sufficient  inconvenience  to  economically  justify  a 
more  rapid  system  response. 

c.  Narrative/Record.  These  are  applications  relating  to  the  delivery 
of  messages  or  other  record  type  transactions  which  are  considered  to  be 
"one  way"  from  a communications  network  point-of-view.  This  category 

is  characterized  by  the  teletype  message  traffic  currently  processed  by 
AUTODIN.  However,  with  the  potential  for  mail  service  deterioration  as 
volume  grows,  it  seems  likely  that  facsimile  transmission  will  place  a 
substantial  demand  on  the  future  DCS.  Accordingly,  the  narrative/record 
transaction  category  is  subdivided  into  "message"  type  traffic  as  we  know 
it  today,  and  facsimile  applications  which  are  considered  to  be  a valid 
requirement  of  the  DCS  in  the  1981-86  time  frame. 

d.  BULK  1 . This  category  comprises  entire  data  files,  programs, 
or  other  data  processing  results  which  are  characterized  by  response 
time  requirements  of  less  than  1 hour  and  by  transaction  lengths 
normally  not  exceeding  10^  bits. 

e.  BULK  2.  This  category  comprises  extremely  lengthy  information 
(normally  in  excess  of  10°  bits),  such  as  an  entire  data  base  or  certain 
sensor  data,  for  which  the  response  time  requirement  is  commensurate 
with  "non-busy  hour"  transmission. 

3.  TRANSACTIONAL  DISTRIBUTION 

a.  Definition.  Transactional  distribution  represents  the  percent- 
age of  total  transactions,  taken  either  onadaily  or  on  a "busy  hour" 
basis,  for  each  of  the  previously  defined  application  categories.  This 
distribution,  in  conjunction  with  the  transaction  parameters  of  average 
length  and  response  time,  provides  a valuable  insight  into  the  required 
communications  network  transfer  rates  and  traffic  load  distributions. 

b.  Source  of  Information.  The  only  definitive  source  of  data 
relating  to  application  distribution  found  in  the  current  literature 
is  the  work  done  by  James  Martin  C7J.  The  importance  of  Martin's  work 
lies  in  the  insight  into  future  traffic  distribution  which  is  pro- 
vided by  his  "relative  popularity  poll."  In  this  poll,  Martin  asked 
approximately  50  systems  analysts,  all  highly  experienced  in  diverse 
areas,  what  they  thought  would  be  the  relative  future  popularity  of 
different  data  transmission  response  time  requirements  and  message 
lengths.  Their  estimates  differed  over  a wide  range;  however,  Martin 
was  able  to  prepare  a composite  diagram,  as  discussed  in  more  detail 
below,  depicting  the  relative  popularity  of  different  data  transmission 
applications  from  which  he  concluded  that  "given  good  line  facilities, 
the  data  transmission  industry  will  grow  in  many  new  directions, 
including  some  that  are  barely  anticipated  today."  This  report  draws 
heavily  on  Martin's  work  in  the  discussions  that  follow. 
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c.  Statistical  Evaluation.  Martin's  "popularity"  chart  as  given 
in  Figure  3 has  been  divided  into  regions  corresponding  to  the  trans- 
action application  categories  defined  in  subsection  2.  The  resulting 
plot  is  shown  in  Figure  4.  The  numbers  lying  within  each  region,  re- 
presenting the  relative  popularity  of  that  combination  of  response  time 
and  transaction  length,  were  then  added  and  normalized  as  a percentage 
of  their  total.  These  percentages  were  then  interpreted  as  the  per- 
centage of  total  transactions  falling  within  that  application  category. 
These  percentages  are  tabulated  in  Table  III  on  both  a daily  and  a busy 
hour  basis.  Conversion  of  daily  transaction  percentages  to  busy  hour 
transaction  percentages  is  based  on  the  following  assumptions: 

(1)  Telemetry  and  status  indication  is  essentially  a 24  hour 
operation  with  no  single  hour  receiving  particular  emphasis. 

• (2)  "Over-the-counter"  operations  such  as  FAX  Mail,  and  to 
some  extent  BULK  1 transmission,  overlap  the  normal  duty  day  and  are 
considered  to  be  represented  in  the  busy  hour  in  a ratio  of  1 in  12. 

(3)  Routine  narrative/record  and  all  BULK  2 transactions, 
handled  in  the  network  as  load  permits,  are  not  considered  to  be  a 
"busy"  hour  design  requirement. 

(4)  All  other  transaction  categories  are  considered  to  be 
accomplished  during  the  normal  duty  day  and  are  therefore  represented 
in  the  busy  hour  in  a ratio  of  1 to  7.5. 

(5)  FAX  Mail  is  considered  to  be  apportioned  among  the  various 
precedence  categories  in  the  same  portion  as  currently  found  in  AUTODIN. 

The  fact  that  the  numbers  derived  from  Martin's  popularity  poll 
can  be  manipulated  in  this  fashion  was  confirmed  by  telephone  with 
Mr.  Martin  at  the  IBM  Systems  Research  Institute  in  New  York.  However, 
three  observations  concerning  the  application  of  Martin's  work  to  the 
DCS  user  environment  should  be  noted: 

• Due  to  differing  economic  considerations  between  the  military 
and  private  sectors  of  the  economy,  particularly  in  the  area 
of  air  transport,  the  trend  towards  facsimile  mail  within  DoD 
may  not  occur  as  rapidly  as  envisioned  by  Martin  for  the  country 
as  a whole. 

• The  significant  requirement  identified  by  Martin  for  two  classes 
of  transactions,  characterized  by  average  transaction  lengths  of 
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Figure  3.  Martin's  Popularity  Poll 
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TABLE  III.  ESTIMATED  APPLICATION  DISTRIBUTION  BY  PERCENTAGE  OF 
TOTAL  TRANSACTIONS 


TYPE  OF  TRANSACTION 

% TOTAL  TRANSACTIONS 

mjggmm 

Daily  Transactions 

Busy  Hour  Transactions 

Interactive 

% 

Human  Inter- 
action 

28% 

41% 

Alarms/Status 

Indicators 

6% 

3% 

Monitoring/ 

Telemetry 

^2% 

6% 

TOTAL: 

46% 

50% 

Inquiry/Response  (None) 

15% 

22% 

Narrative/ 

Record 

> 

Flash/Flash 

Override 

0.1% 

(.2)% 

Inmediate 

1.4% 

2% 

Priority 

5.0% 

8% 

Routine 

6.1% 

- 

Fax  Mail 

14.4% 

7% 

TOTAL: 

27% 

17% 

BULK  1 

(None) 

12% 

11% 

BULK  2 

(None) 

(0.05)% 

- 
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4 X 10^  and  7 x 10^  bits  with  a response  time  on  the  order  of 
1 second,  appears  to  correlate,  with  possible  requirements  for 
"battlefield"  TV  and  other  large  volume  critical  sensor  requirements. 
These  requirements,  although  recognized,  are  considered  to  be  beyond 
the  scope  of  the  DCS  switched  data  network  for  the  foreseeable  future 
and  were  deleted  from  the  calculations. 

e It  was  found  that,  due  to  a substantial  difference  between  the 
average  transaction  length  assumed  for  BULK  2 transactions  and 
the  average  transaction  lengths  assumed  for  the  remaining  cate- 
gories, a change  of  a single  percentage  point  for  the  relative 
distribution  of  BULK  2 transactions  had  a considerable  impact  on 
the  projected  network  loading.  Since  Martin  did  not  intend  his 
"poll"  to  be  viewed  with  this  degree  of  accuracy,  the  initial  value 
of  3%  computed  for  BULK  2 distribution  from  Martin's  chart  has  been 
. replaced  with  the  value  of  0.05%,  based  on  an  engineering  judgment 

which  would  indicate  that  each  computer,  on  the  average,  will  not 
generate  more  than  two  BULK  2 category  transactions  per  day  during 
the  interim  (1980-86)  time  period.  Due  to  the  importance  of  this 
estimate  to  the  relative  balance  between  "busy  hour"  and  "non- 
busy hour"  traffic  applications,  the  subject  of  BULK  2 transaction 
rates  will  receive  special  consideration  during  the  upcoming  IAS 
studies. 

4.  RESPONSE  TIME 

a.  Definition.  The  time  a teleprocessing  system  takes  to  respond 
to  a given  input  is  referred  to  as  the  response  time  for  that  sybtem. 

More  specifically,  response  time  can  be  considered  from  two  viewpoints, 
depending  on  the  particular  application  being  considered. 

(1)  Interactive  Systems.  For  operation  between  a computer  and 
a remote  terminal,  response  time  is  defined  as  the  time  interval  between 
the  operator  pressing  the  last  key  (or  enter  key)  of  the  input  message 
and  the  terminal's  indication  of  the  first  character  of  the  reply.  It  is 
similarly  defined  for  other  kinds  of  interactive  information  transfer 
systems  as  the  interval  between  an  event  and  the  system's  response  to  that 
event.  Strictly  speaking,  receipt  of  the  first  complete  "thought"  rather 
than  the  first  character  of  the  reply  is  the  major  concern  to  most  inter- 
active terminal  users.  However,  the  difference  in  time  between  the  receipt 
of  the  first  character  and  the  first  "thought"  is  a function  of  terminal 
speed,  v^hich  should  have  been  properly  selected  by  the  user  for  the  applica- 
tion at  hand.  Accordingly,  the  fine  point  of  "thought"  receipt  versus 
character  receipt  can  generally  be  ignored  by  the  commi cations  network 
designer. 
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(2)  Information  Delivery  Systems.  Where  information  transfer  is 
not  interactive,  it  is  more  appropriate  to  specify  a "delivery  time" 
rather  than  a response  time.  Within  this  context,  delivery  time  refers  to 
situations  in  which  information  is  considered,  from  a cottmuni cations  view- 
point to  be  flowing  only  in  one  direction,  and  can  be  defined  as  that  time 
interval  between  the  start  of  transmission  at  the  sending  location  and  the 
completion  of  reception  at  the  receiving  station.  This  definition  differs 
from  that  of  "Response  Time"  because  in  most  "Delivery  Time"  applications, 
the  communications  service  is  considered  to  be  "over-the-counter"  from 
the  customer's  viewpoint  (i.e.,  the  customer  does  not  provide  the  terminals). 
Accordingly,  selection  of  the  proper  terminal  device  is  in  this  case  more 
appropriately  a communications  network  design  issue. 

b.  Source  of  Information.  Although  based  for  the  most  part  on  very 
limited  data,  the  response  time  and  delivery  time  criteria  reported  by 
previous  DCEC  studies  and  extracted  from  MilDep  requirement  submissions, 
are  summarized  in  Table  IV  together  with  the  applicable  AUTODIN  statistics. 

In  addition,  valuable  insight  gained  from  the  work  done  by  Martin  is  also 
reflected  in  the  table,  both  in  terms  of  application  boundary  values  and 

in  expected  values  derived  from  Martin's  "Popularity  Poll"  by  contour 
plotting  as  depicted  in  Figure  5. 

c.  Statistical  Evaluation 

(1)  The  Gamma  Distribution.  In  Martin's  report  [7],  a rule 
of  thumb  for  response  time  calculations  is  given  which  concludes  that 
response  time  follows  a gamma  distribution  where  the  95  percentile  of 
response  time  is  close  to  the  mean  response  time  plus  two  standard 
deviations,  and  the  minimum  response  time  is  close  to  the  mean  minus 

one  standard  deviation.  This  rule  of  thumb,  hereafter  referred  to  as  the 
Gamma  Assumption,  is  shown  graphically  in  Figure  6.  The  benefit  to  be 
derived  from  the  Gamma  Assumption  is  that  only  two  of  the  three  attributes 
of  response  time  (i.e.,  the  minimum,  the  mean,  and  the  maximum  values) 
need  be  specified,  since  the  third  can  be  calculated. 

(2)  Human  Factors  Considerations.  In  addition  to  purely  sta- 
tistical considerations,  the  following  human  factor  considerations 
reported  by  Miller  [8],  Martin  and  others  [7]*  are  especially  important 
to  any  discussion  of  interactive  response  time: 

• In  general,  delays  greater  than  IE  seconds  rule  out  conversa- 
tional dialogue.  As  Miller  puts  it,  "if  delays  of  more  than 
15  seconds  will  occur,  the  system  had  better  be  designed  to  free 
the  user  from  physical  and  mental  activity  so  that  he  can  turn  to 
other  activities  and  get  his  displayed  answer  when  it  is  convenient 
for  him  to  do  so." 


TABLE  IV.  RESPONSE  TIME  STATISTICS  (USER-TO-USER) 
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FIGURE  6.  THE  GAMMA  ASSUMPTION 
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• In  some  cases  it  has  been  claimed  that  too  short  a response 

time  is  psychological ly  bad.  Subconsciously,  the  operator  feels 
coerced  into  an  attempt  to  keep  up  with  the  machine.  In  general, 
it  appears  that  1.5  seconds  is  the  minimum  value  for  response 
time  where  human  operators  are  concerned. 

(3)  "Average"  Response  Time  Statistic.  Using  the  Gamma  Assump- 
tion together  with  the  insight  provided  by  the  statistics  given  in  label 
IV  and  the  human  factor  considerations  outlined  above,  response  time 
criteria  for  the  DCS  data  users  were  developed  in  terms  of  the  delay 
acceptable  in  a passage  throught  the  communications  network;  these  are 
tabulated  in  the  right  hand  column  of  the  table. 

5.  TRANSACTION  LENGTH 

a*.  Definition.  Transaction  length  can  be  considered  from  two 
aspects:  from  that  of  an  "average"  transaction  having  an  average  length, 
or  from  that  of  specific  transactions  having  a length  which  is  either 
constant  or  varies  as  some  identifiable  function  of  a defineable  force 
parameter(s) , such  as  troop  population,  number  of  aircraft,  etc.  The 
"average"  transaction  approach  is  taken  in  this  report  because  current 
data  relating  transaction  length  to  force  parameters  is  lacking.  The 
specification  of  transaction  length  as  a function  of  force  parameter  is 
currently  under  study  in  DCEC  and  will  be  more  fully  addressed  in  developing 
the  User  Requirement  Data  Base. 

b.  Source  of  Information.  Although  based  for  the  most  part  on  very 
limited  data,  the  transaction  length  statistics  reported  in  previous 
studies  and  extracted  from  recent  MilDep  requirement  submissions  are 
summarized  in  Table  V,  together  with  the  applicable  AUTODIN  I statistics. 

As  discussed  previously,  valuable  insight  into  the  average  transaction 
lengths  to  be  anticipated  for  future  data  requirements  was  gained  from 
the  work  done  by  Martin.  This  information  is  given  in  Table  V,  both 

in  terms  of  application  boundary  values,  and  in  terms  of  expected  values 
derived  from  a contour  plot  of  Martin's  "Popularity  Poll"  (Figure  5). 

c.  Statistical  Evaluation.  A comparison  of  previous  transaction 
statistics  to  Martin's  boundary  values  lends  considerable  credence 

to  applying  Martin's  work  to  the  DCS  user  environment.  Using  these 
statistics  as  a basis  for  discussion,  average  transaction  lengths  in 
terms  of  information  bits  to  be  transferred  have  been  estimated  for 
the  purpose  of  establishing  a baseline  statistic  and  are  tabulated  in  the 
right-hand  column  of  Table  V.  Figures  associated  with  a slash  denote 
Inquiry/Response  transaction  lengths*  and  are  assumed  to  be  found  in 
the  communications  network  in  the  ratio  of  two  responses  for  every 
three  inquiries  to  reflect  data  base  update  transactions  for  which  no 
response  other  than  an  acknowledgment  of  receipt  is  required, 

* The  left  hand  figure  represents  "Inquiry,"  and  the  right  hand  figure 
"Response, " 
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TABLE  V.  AVERAGE  TRANSACTION  LENGTH  STATISTICS  (IN  BITS) 


600/^00  represents  the  Inquiry  and  response  transaction  lengths  respectively. 
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6.  TRAFFIC  PROJECTIONS  ! 

i 

a.  Definition.  Traffic  projections  are  generally  developed  in  either  j 

of  two  ways.  The  first  way  is  from  the  "bottom-up,"  wherein  detailed 

traffic  statistics  and  community  of  interest  information  are  gathered  or 
postulated  for  each  user  element  in  the  population  being  evaluated,  and 
then  added  to  arrive  at  a comprehensive  traffic  matrix  depicting  the  inter- 
action between  the  various  elements  of  the  population.  The  second  way  is 
from  the  "top-down,"  by  first  projecting  a value  for  total  traffic  demand 
based  on  some  generalized  model  of  the  subscriber  community,  and  then  appor- 
tioning this  total  among  the  various  user  elements.  Apportioning  schemes 
can  be  based  on  computer  core  densities,  base  population,  or  some  other 
estimator  relating  traffic  to  geographic  area  of  location.  The  bottom-up 
method  can  provide  a much  more  accurate  picture  of  requirement  demand,  but 
to  achieve  this  accuracy  requires  considerable  insight  into  the  activity 
of  and  interrelationships  between  the  various  users  in  the  community.  This 
insight  is  available  for  only  a few  specialized  communities  at  present,  but 
is  being  expanded  by  current  DCEC  efforts.  However,  sufficient  data  on 
which  to  base  a comprehensive  DoD  wide  projection  of  user  demand  will  not 
be  available  before  the  fall  of  1977.  Accordingly,  the  top-down  approach 
was  used  in  developing  the  requirement  projections  presented  in  this  report. 

b.  Source  of  Information.  Many  attempts  have  been  made  in  the  past 
to  project  a value  for  total  data  traffic  to  be  supported  by  the  DCS  in 
the  1980-1985  time  period.  Broadly  speaking,  these  efforts  can  be  divided 
into  three  somewhat  similar  approaches,  each  of  which  arrives  at  approxi- 
mately the  same  total  value  of  3x10^^  bits  per  day  in  the  mid  --  1980 
time  period. 

(1 ) Traffic  Projection  for  the  DCS  Plans  FY  72/82  Through  FY 
75/85.  Several  projected  values  for  total  future  data  traffic  based  on 
the  work  done  at  the  DCA  System  Engineering  Facility  during  1971-1972  [9] 
have  been  reported  in  past  DCA  Long  Range  Plans  tlOl,  [111,  [121.  These 
projections  are  based  on  an  assumed  rate  of  growth  for  user  terminals  to 
be  supported  by  the  DCS  at  some  particular  time  in  the  future,  and  on 
certain  assumptions  concerning  relative  distribution  of  terminal  data  rates, 
terminal  utilization  factors,  and  the  percentage  of  terminal  traffic 

expected  to  transit  the  DCS.  The  traffic  values  thus  derived  are  added  ■ 

to  figures  similarly  developed  for  computer-to-computer  application,  and  j 

for  local  Digital  Message  Exchange  (LDMX)  and  non-LDMX  narrative/record 
traffic  derived  from  AUTODIN  Statistics  and  Base  Population  figures. 

(2)  Traffic  Projection  for  the  AUTODIN  II  Program.  A projection 
technique  similar  to  that  utilized  for  the  Long  Range  Plans  was  developed 
by  the  Defense  Communications  Engineering  Office  during  1973-1974  [13]. 

This  projection  utilized  terminal  growth  rates  and  computer/terminal  inter- 
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action  patterns  developed  during  the  initial  AUTODIN  II  study  effort. 

This  information  was  augmented  by  the  transaction  statistics  derived  in 
part  from  the  work  done  by  Martin  and  others,  as  previously  discussed. 

This  effort  went  beyond  previous  efforts  in  that  the  total  traffic  value 
once  derived  was  then  geographically  apportioned  within  the  DoD  community 
on  the  basis  of  relative  computer  core  densities  as  projected  by  the  General 
Service  Administration  (GSA)  for  DoD  [14]. 

(3)  Traffic  Projection  for  the  DCS  Plan  FY  76/86.  The  traffic 
projection  techniques  employed  in  the  DCS  Plan  FY  76/86  essentially  combined 
the  two  previous  approaches,  refining  considerably  the  estimates  for  com- 
puter/terminal growth  and  the  spread  of  future  ADP  system  applications. 

The  near  and  mid-term  traffic  projections  for  this  report  are  taken  from 
this  source. 

• c.  Statistical  Evaluation 

(1)  A Conservative  Projection.  The  traffic  projection  in  support 
of  the  DCS  Plan  FY  76/86  was  developed  by: 

• First,  characterizing  existing  military  installations  in  terms  of 
their  size,  function,  and  automatic  data  processing  (ADP)  equipment. 
From  this,  profiles  of  military  locations  were  developed  in  terms 
of  their  ADP  and  data  communications  needs.  These  resulting  base 
profiles  postulated  the  number  of  computers  and  terminals  required 
for  a typical  base  or  location  of  a particular  size  and  function. 

• Next,  postulating  the  volume  of  traffic  generated  at  each  computer 
and  terminal.  The  user  modes  were  identified  as  data  terminals 
(low  speed  and  high  speed),  computer,  and  narrative  - with  nominal 
transmission  rates  of  450  b/s  and  3600  b/s,  4800  b/s,  and  300  b/s 
respectively.  The  nominal  time  per  user  transaction  and  the  nominal 
number  of  transactions  in  the  busy  hour  were  then  estimated  using 
military  ADP  systems,  the  professional  literature.  Volume  III  of 
the  DCS  Plan  75/85,  and  engineering  judgment  as  guidelines.  By 
multiplying  these  quantities,  the  average  information  bits  generated 
in  the  busy  hour  were  obtained  for  each  class  of  user  terminal. 

• Finally,  combining  the  base  profiles,  which  represented  the  total 
number  of  computers  and  terminals  in  1986,  with  the  estimated 
volume  of  traffic  generated  per  computer  and  terminal.  This  com- 
putation resulted  in  a total  daily  traffic  volume  of  3.34  x 10^' 
bits  per  day,  approximately  10%  greater  than  estimated  in  the  DCS 
plan  FY  75/85.  If  a lower  bound  of  2,000  or  an  upper  bound  of 
3,000  on-line  computers  is  used,  daily  traffic  volume  will  vary  from 
approximately  2,61  x 10*'  bits  to  3.91  x lO''  bits  per  day. 
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The  upper  and  lower  bounds  to  the  number  of  computers  expected  to  be 
"on-line"  by  1985  were  developed  in  the  following  manner: 

• Lower  Bound  - A review  of  DoD  ADP  systems  currently  installed 
or  approved  for  installation  by  1978  indicated  a total  of  2,374 
computers  for  that  time  period.  Eighty  five  percent  of  these 
computers  were  considered  as  likely  to  be  on-line  in  the  1986  time 
frame.  Accordingly,  the  figure  of  2,000  was  taken  as  a reasonable 
lower  bound  for  the  number  of  computers  "on-line"  in  1986. 

I Upper  Bound  - Adding  to  the  ADP  system  assets  considered  in  the 
lower  bound  calculation  all  shipboard  computers,  scientific  com- 
puters at  non-military  locations,  and  other  DoD  computer  assets 
identified  in  the  GSA  Inventory  of  Automatic  Data  Processing 
Equipment  [14],  a total  figure  of  3,500  was  established  for  com- 

. puters  which  could  exist  in  1978.  Applying  the  same  85%  figure 
as  used  in  the  lower  bound  calculations,  a figure  of  3,000  was 
proposed  as  a reasonable  upper  bound  for  the  number  of  computers 
"on-line"  in  1986. 

The  DCS  Plan  FY  76/86  traffic  projection  is  based  on  a postulated 
increase  in  interaction  between  computer  assets  essentially  in-being 
in  1978-1979,  and  does  not  consider  the  more  revolutionary  developments 
which  may  occur  in  data  transfer  applications  such  as  Fax-Mail,  central 
document  respositories,  or  the  possible  proliferation  of  "cheap"  data 
terminals  at  each  "desk."  Accordingly,  this  traffic  projection  is 
considered  to  be  overly  conservative  when  applied  to  the  post  - 1980/82 
time  frame. 

(2)  An  Optimistic  Projection.  In  considering  the  potential 
impact  of  new  and  innovative  applications  for  data  transfer  as  discussed 
earlier  in  this  report,  it  is  not  unreasonable  to  expect  a traffic  volume 
in  the  mid-1980's  of  one  to  two  orders  of  magnitude  above  that  projected 
by  the  more  conservative  on-line  computer  projection  approach.  This  higher 
order  projection  is  given  additional  weight  by  the  literature  which  is 
replete  with  examples, of  gross  underestimation  of  future  requirements. 
Accordingly  132  x lo'  bits  per  day,  as  a compromise  between  one, and  two 
orders  of  magnitude  above  the  conservative  estimate  of  3.34  x 10  bits, 
is  considered  an  optimistic  upper  bound  to  the  traffic  volume  expected 
in  the  1986  time  frame. 


(3)  The  "Most  Likely"  Projection.  Noting  that  the  current 
communications  networks  are  constrained,  at  least  in  terms  of  speed 
of  service  and  transfer  protocols,  and  the  fact  that  new  applications 
for  data  transfer  generally  emerge  only  when  a clear  economic  or  other 
specific  advantage  is  perceived  by  the  potential  user,  it  is  expected 
that  actual  "validated"  data  transfer  requirements  will  lag  behind  even 
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the  conservative  traffic  projection  until  around  1980,  when  the  enhanced 
capabilities  of  AUTODIN  II  become  available.  During  this  period,  the 
annual  budget  pinch  together  with  the  probability  that  requirements  do  not 
emerge  as  rapidly  as  the  "forecasters"  projected,  will  lead  top  manage- 
ment to  take  a "wait  and  see"  approach  concerning  additional  communications 
program  expansion. 

Early  in  the  1980  time  period,  with  AUTODIN  II  and  cheaper  "smart" 
terminal  designs  available,  data  transfer  requirements  will  reflect  the 
pent-up  demand  resulting  from  an  increasing  economic  advantage  for 
electronic  transmission.  This  rate  of  requirement  growth  should  exceed 
the  conservative  projection  by  1982  or  1983,  and  continue  until  the 
application  design  limits  of  the  AUTODIN  II  network  are  reached,  most 
likely  in  1985  or  1986. 

. With  the  rapidly  increasing  demand  for  data  transfer  clearly 
visible  by  1982,  together  with  an  enhanced  requirement  forecasting 
posture  within  the  DoD  community,  top  management  will  recognize  the  long 
prophesied  "Information  Age"  as  an  emerging  reality  and  will  approve  new 
and  innovative  communications  system  programs  in  keeping  with  the  pace 
and  direction  of  the  expanding  data  revolution.  The  fact  that  implementa- 
tion generally  lags  planning  from  5 to  7 years  will  tend  to  damp  actual 
data  transfer  growth  until  the  full  third-generation  system  capability 
becomes  available  around  1988  or  1989. 

The  conservative  and  optimistic  traffic  growth  projections  together 
with  the  expected  path  of  traffic  demand  are  shown  in  Figure  7.  The 
1986  busy  hour  and  daily  traffic  totals  expected  for  the  five  applica- 
tion categories  are  shown  in  Tables  VI  and  VII  respectively  for  each  of 
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PROJECTION 

CONSERVATIVE 

PROJECTION 

INTERACTIVE 

Human  Interaction 

1.61  X lo’° 

8.77  X 10® 

4.01  X 10® 

Alarms/Status  Indicators 

6.50  X 10^ 

3.55  X lo'* 

1.62  X 10*^ 

Monltoring/Telemetry 

4.67  X 1.0® 

2.55  X 10^ 

1.17  X 10^ 

INQUIRY/RESPONSE 

8.6’  X 10® 

4.69  X 10® 

2.15  X 10® 

NARRATIVE  RECORD 

Flash/Flash  Override 

1.87  X. 10® 

1.02  X 10^ 

4.68  X 10® 

Immediate 

4.08  X 10® 

2.23  X 10® 

1.02  X 10® 

Priority 

E.l9x  10’° 

1.19  X 10® 

5.45  X 10® 

Routine 

— 

...  - 

Fax  Man 

3.60  X lo’° 

1.96  X 10® 

9.00  X 10® 

BULK  1 

7.8  X 10^’ 

4.26  X 10^® 

1.95  X 10’° 

BULK  2 

. - - - 

- - - - 

TABLE  VI.  THE  1986  TOTAL  BUSY  HOUR  TRAFFIC  FOR  EACH 
APPLICATION  CATEGORY  ( IN  BITS) 
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TABLE  VII.  THE  1986  TOTAL  DAILY  TRAFFIC  FOR  EACH 
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IV.  MAJOR  FUNCTIONAL  REQUIREMENT  ATTRIBUTES 


1.  SPECIAL  SERVICE  FEATURES 

In  addition  to  the  basic  information  transfer  requirement  characteri- 
zation discussed  in  the  previous  section,  additional  service  features 
may  be  desired.  Certain  of  these  special  features  may  place  an  added 
demand  on  the  communications  network  design,  while  others,  more  appro- 
priately considered  a function  of  the  automatic  data  processing  system, 
may  only  indirectly  affect  traffic  volume  or  the  requirement  for  special- 
ized terminal  design.  To  clarify  the  extent  of  communications  system 
design  responsibility,  both  of  these  categories  are  addressed  in  the 
following  discussions. 

a.  Speed  Conversion.  A teleprocessing  system  has  three  components 
that  may  be  incompatible  in  speed:  the  computer,  the  terminal,  and  the 
communications  network  interlinking  them.  Normally,  this  problem  is  re- 
solved by  the  use  of  buffers  located  within  the  ADP  system  or  the  communi- 
cations network,  or  within  both.  For  narrative/record  traffic,  speed 
conversion  is  principally  achieved  within  the  communications  network 
via  the  buffering  action  of  the  store-and-forware  switch,  although,  to 
a much  lesser  extent,  the  continued  use  of  paper  tape  at  some  low  speed 
terminals  is  considered  to  be  a form  of  terminal  buffering.  For  computer- 
to-computer  and  terminal -to-terminal  interaction,  the  buffers  are  generally 
located  within  the  host  computer  complex,  although  a small  but  growing 
population  of  so  called  "smart"  terminals  is  being  developed  to  do  editing, 
error  control,  and  other  logic  functions  at  the  terminal  in  addition  to 
speed  conversion.  Except  for  the  relatively  few  "smart"  terminals,  this 
solution  is  generally  limited  to  a single  ADP  system,  and  does  not  provide 
the  capability  for  direct  communications  between  terminals  operating  at 
different  speeds,  or  between  terminals  of  one  ADP  system  and  the  terminals 
and/or  computers  of  another  ADP  system  which  are  not  speed  compatible. 

The  cost  of  buffering  within  the  terminals,  once  high,  has  fallen 
substantially  in  recent  years  as  a result  of  the  advances  in  LSI 
technology.  However,  a preponderance  of  unbuffered  terminals  is  still 
projected  through  the  1976/80  time  period.  Therefore,  economic  considera- 
tions, as  well  as  the  need  for  flexible  interchange  between  dissimilar 
ADP  systems,  dictate  a continuing  need  for  speed  conversion  as  a service 
feature  of  the  communications  network.  By  the  1980/85  time  period,  however, 
it  is  conceivable  that  large  base  concentrators  may  prevail  as  the  inter- 
face between  the  user  and  the  long  haul  DCS.  The  remaining  terminals 
requiring  direct  access  to  the  long  haul  DCS  will  most  likely  be  of  the 
"smart"  variety  in  order  to  benefit  from  a more  efficient  utilization  of 
the  access  line,  thus  reducing  or  eliminating  entirely  the  need  for  speed 
conversion  at  the  switching  nodes  of  the  communications  network. 
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b.  Code  Conversion.  A variety  of  data  text  codes  are  presently 
in  use  within  the  various  ADP  systems  in  response  to  differing  data 
structure  considerations.  Although  ASCII  is  being  stressed  as  the 
standard  code  for  information  interchange  and  has  been  adopted  as  the 
standard  for  narrative/record  traffic  passing  through  AUTODIN,  it  does 
not  appear  that  a single  data  text  code  will  be  acceptable  to  all  ADP 
users  anytime  in  the  near  future.  Since  it  is  desirable  for  devices 
that  use  different  codes  to  be  able  to  communicate,  some  form  of  code 
conversion  is  required,  either  within  the  ADP  system  or  as  a service 
provided  by  the  communications  network.  Which  alternative  should  be 
selected  in  a particular  case  depends  on  economic  and,  in  some  cases, 
response  time  considerations. 

With  respect  to  code  conversion,  information  transfer  requirements 
can  be  placed  in  one  of  three  categories.  The  first  addresses  narrative/ 
(Record  type  transactions  for  which  a standardized  teleprocessing  code 
(ASCII)  has  been  adopted  and  appears  satisfactory  as  a continuing  solution 
for  subscriber  needs.  The  second  category  involves  computer-to-computer 
information  transfer  or  terminal -to-computer  interaction  between  ADP 
systems  wherein  such  interactions  are  considered  a common  occurrence  for 
at  least  one  of  the  systems.  In  this  case,  code  conversion,  if  required, 
can  usually  be  provided  most  cost-effectively  by  the  central  computer  of 
one  of  the  ADP  systems,  most  likely  the  system  for  which  interaction  is 
the  most  common  occurrence.  The  last  category  involves  terminal -to- 
terminal  or  terminal -to-computer  interaction  between  ADP  systems  wherein 
such  interaction  is  uncommon  for  either  system.  In  this  case  it  would 
appear  that  code  conversion,  if  required,  would  be  more  economically 
provided  as  a service  feature  of  the  communications  network  --  at  least 
until  the  present,  relatively  unintelligent  terminals  are  replaced  by 
"smart"  terminals,  as  discussed  previously  in  subparagraph  a.  In  any 
case,  the  communications  network  should  provide  transparency  to  the 
user's  transaction  or  data  text  code,  ensuring  that  there  are  no  restric- 
tions as  a result  of  the  communications  control  code  adopted  for  network 
processing. 

c.  Format  Conversion.  Data  formats  used  for  information  transfer 
within  the  communications  network  can  differ  widely  for  seemingly  similar 
ADP  systems.  The  format  structure,  other  than  for  transfer  protocols, 
involves  the  very  nature  of  the  data  being  interchanged  and  as  such  is 
not  amenable  to  manipulation  within  the  communications  network.  Network 
transfer  protocols,  of  necessity,  will  continue  to  be  dictated  by  communi- 
cations network  design  considerations. 

d.  Editing.  Editing  collectively  represents  a number  of  administra- 
tive functions  that  logic  circuitry  located  within  the  terminal,  within 
the  switching  nodes  of  the  communications  network,  or  within  the  host 
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computer  complex,  can  perform  as  an  additional  service  for  the  tele- 
processing user.  These  functions  can  take  the  form  of  simple  text 
editing,  printout/display  formating,  routing  table  lookup  and  address 
formating,  "header"  and  "trailer"  generation,  etc.  The  value  of  addres- 
sing these  services,  whether  within  the  ADP  or  communications  system 
design,  is  again  a matter  of  economics.  In  regard  to  editing,  it  would 
appear  that  those  services  associated  with  the  information  text  itself, 
or  the  special  communications  feature  which  cannot  be  abbreviated  and 
vary  from  transmission  to  transmission,  are  more  appropriately  addressed 
in  the  terminal  design  (although  certain  services  such  as  text  editing 
may  continue  to  be  performed  manually  or  provided  by  a distant  host 
computer  for  those  applications  where  an  "intelligent"  terminal  is  not 
considered  cost  effective).  It  is  generally  more  economical  to  provide 
routine  services,  such  as  routing  table  lookup,  within  the  switching 
nodes  of  the  communications  network  by  the  assignment  of  appropriate 
class-marks  or  other  logic  features. 

e.  "Mail  Box"  Service.  Narrative/record  traffic,  and  to  some 
extent  inquiry/ response  traffic,  may  be  submitted  to  the  communications 
network  for  delivery  at  a time  not  convenient  to  the  addressee,  either 
because  of  a busy  terminal  cond''-'on  or  because  delivery  is  attempted 
outside  of  normal  duty  hours  ;jith  respect  to  this  problem,  a "Mail 
Box"  service  such  as  presently  offered  in  the  ARPA  network,  or  to  a more 
limited  extent  by  the  AUTODIN  store-and-forward  message  service,  is  a 
continuing  requirement  for  the  communications  network. 

f.  Security  and  Privacy.  The  users  of  the  communications  network 
may  transfer  information  which  is  classified  or  which  contains  informa- 
tion about  private  individuals  or  other  proprietary  subjects  that  must 
be  kept  confidential.  Keeping  such  information  out  of  unauthorized 
hands  is  an  extremely  important  requirement  placed  on  the  communications 
network.  Equally  important  is  the  need  to  prevent  unauthorized  access 
to  the  ADP  systems  served  by  the  communications  network  for  the  purpose 

of  changing  data  files  or  otherwise  tampering  with  the  ADP  system  structure. 
Denying  such  access  is  essential  to  preclude  fraud,  sabotage,  or  other 
unauthorized  operation,  and  is  a requirement  to  be  shared  equally  by 
the  ADP  system,  the  terminal,  and  the  communications  network  design. 

g.  Management  Statistics.  In  order  to  monitor  ADP  system  operation 
effectively  or  otherwise  manage  their  teleprocessing  resources,  both  the 
user  and  the  communications  network  manager  will  require  certain  statistical 
information  from  the  communications  network  in  addition  to  that  normally 
maintained  by  the  terminal  operator.  The  information  envisioned  as  being 
required  can  be  grouped  into  the  eight  interrelated  prime  factors  shown  in 
Table  VIII,  and  is  seen  to  be  little  different  from  that  now  required 

for  communications  network  management.  The  first  two  factors  relate 
to  the  cost  of  service  and  provide  the  measure  necessary  for  the  ADP  system 
manager  to  weigh  alternative  solutions  to  his  teleprocessing  needs.  The 
next  three  factors  contribute  to  the  same  general  functions  of  monitoring 
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TABLE  VIII.  APPLICATION  AREAS  FOR  MANAGEMENT  STATISTICS 


Application  Areas 

ADP 

Manager 

Network 

Manager 

Service  Costs 

X 

Transaction  Statistics 

X 

X 

Equipment  Performance  Status  Monitoring 

X 

X 

and  Analysis 

Circuit  Performance  Status  Monitoring  and 

X 

X 

Analysis 

System  Performance  Status  Monitoring  and 

X 

Analysis 

Fault  Isolation 

X 

Decision  Selection 

X 

Maintenance  Control 

X 

X 
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and  analysis  and  are  applied  to  the  three  teleprocessing  levels  of  major 
concern.  The  last  three  factors  relate  to  maintaining  communications 
continuity  and  are  of  primary  interest  to  the  communications  network 
manager.  In  this  regard,  full  time  and/or  rapid  sequential  scanning  of 
selected  parameters  should  be  computer  controlled,  then  analyzed  and 
compared  against  preselected  thresholds.  Trouble  or  impending  difficulty 
should  be  reported  both  to  the  user  facility  and  to  a central  system 
control  point  for  equipment  and  circuit  related  problems,  and  to  the 
central  system  control  for  other  network  related  problems.  Reporting 
should  be  by  exception  so  that  even  with  continual  sampling  and  storage 
of  status  information,  only  those  items  varying  from  predetermined  norms 
would  be  automatically  reported.  One  should  be  able  to  extract  periodic 
reports  on  demand  by  selecting  only  that  data  relevant  to  the  analysis 
at  hand.  It  should  also  be  possible  to  dump  historic  data  for  in-depth 
analysis  when  appropriate. 

h.  Off-Hook  Service.  In  those  ADP  systems  wherein  the  terminal 
communicates  only  with  a single  location  or  computer,  off-hook  service 
could  be  an  essential  requirement  of  the  communications  network.  Other 
ADP  systems  may  require  programmed  altroute  service  as  a method  for 
switch  bypass  should  normal  communications  service  be  disrupted.  In 
this  manner  interswitch  trunk  assets  would  be  assigned  to  certain  high 
priority  subscribers  in  the  event  of  switch  failure,  giving  the  advan- 
tages of  both  the  switched  network  and  today's  special  purpose  networks 
at  a much  more  reasonable  cost. 

2.  SPECIAL  NETWORK  CONSIDERATIONS. 

In  addition  to  the  basic  user  requirement  attributes  and  special 
service  features  discussed  above,  inherent  communications  network  design 
characteristics  heavily  impact  the  alternatives  available  to  the  user.  A 
thorough  insight  into  this  area  is  required  of  both  the  ADP  system  and 
the  communications  network  designers  in  order  to  optimize  the  various 
design  tradeoffs  jointly  available  to  them.  In  this  report,  this  aspect 
of  user  requirement  definition  is  referred  to  as  Special  Network  Con- 
siderations, and  includes  network  availability,  network  survivability, 
network  error  control,  and  external  network  access. 

a.  Network  Availability.  Network  availability  from  a user's  point 
of  view  has  two  aspects:  The  first  concerns  the  degree  of  certainty  of 
obtaining  initial  access  to  the  communications  network,  while  the  second 
concerns  the  continuity  of  service  once  intial  access  is  achieved.  These 
two  aspects  of  availability  may  or  may  not  be  couched  in  the  same  terms. 

In  some  systems,  such  as  command  and  control,  it  is  necessary  to  have  both 
a high  degree  of  certainty  of  obtaining  access  to  the  communications  net- 
work and  a high  degree  of  certainty  that  information  transfer  will  not 
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be  interrupted  once  intiated.  In  other  applications,  such  as  the  monthly 
transfer  of  large  volumes  of  payroll  data,  a wait  of  hours  for  network 
access  can  be  tolerated,  while  a high  degree  of  certainty  that  information 
transfer  will  not  be  interrupted  once  initiated  is  needed  to  preclude 
costly  and  inefficient  retransmission.  Other  user  requirements  range 
between  these  two  extremes,  as  measured  by  an  appropriate  traffic  pro- 
cessing priority  derived  from  the  user's  mission  criticality,  and  his 
type  of  data  transfer  application,  as  shown  in  Table  IX.  As  an  aid  to 
network  design,  the  estimated  percentage  of  total  transactions  for  each 
of  the  traffic  processing  categories  is  given  in  Table  X for  the  busy-hour, 
and  in  Table  XI  for  total  daily  traffic.  These  percentages  are  based 
on  the  projected  transactional  distributions  presented  in  Table  III  and 
the  current  distribution  of  AUTODIN  traffic  by  message  precedence. 

(1)  Connection  Delay.  The  time  between  the  user's  request 
for  communications  network  access  and  the  receipt  of  an  appropriate 
acknowledgement  that  network  access  has  been  achieved  is  defined  as 
connection  delay.  The  connection  delay  which  can  be  tolerated  will 
vary  from  user  to  user,  depending  on  type  of  application  and  impact 
on  the  user's  mission.  Although  insufficient  data  have  been  received 
from  potential  users  concerning  what  connection  delay  can  be  tolerated, 
the  criteria  specified  in  Table  XII  are  considered  to  be  fully  res- 
ponsive to  the  large  majority,  if  not  all,  of  the  data  transfer  re- 
quirements envisioned  for  the  DCS  through  the  1981-1986  time  frame. 

In  reference  to  this  table,  connection  delays  for  each  category  should 
not  exceed  the  time  T for  more  than  the  specified  percent  of  the  time. 

(2)  Service  Interruption.  This  condition  applies  to  those 
situations  wherein  the  data  transfer  has  been  initiated  but  aborted 
completely  for  some  reason  beyond  the  control  of  the  user,  and  retrans- 
mission must  be  initiated.  Again,  little  information  is  available  con- 
cerning what  level  of  service  interruption  is  acceptable  to  the  user. 
However,  any  experience  with  today's  AUTOVON  network  should  convince 
the  skeptic  that  that  level  has  been  exceeded  as  far  as  the  non-command 
and  control  Analog  FAX  or  Bulk  II  data  user  is  concerned.  Currently, 
the  importance  placed  on  continuity  of  service  in  both  the  AUTOVON 

and  AUTODIN  networks  is  based  on  a message  or  call  precedence  scheme 
assigned  on  the  basis  of  assumed  impact  on  national  security.  In  order 
to  be  responsive  to  the  future  data  user,  this  area  must  be  expanded 
to  include  economic  considerations,  such  as  work  processing  efficiencies, 
as  well.  Accordingly,  the  criteria  specified  in  Table  XIII  for  each 
data  transfer  application  category  are  deemed  essential  to  achieving 
an  acceptable  level  of  service  by  the  communications  network. 

b.  Network  Survivability.  Survivability  from  the  viewpoint  of 
the  user  covers  a multitude  of  concerns,  but  probably  the  least  of 
these  is  communications  network  survivability  other  that  in  terms  of 
availability.  However,  due  to  the  wording  of  the  current  DCS  planning 
factor  for  network  survivability  in  terms  of  "user"  survivability, 
this  subject  merits  separate  consideration  under  the  definition  of 
user  requirements. 
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TABLE  IX.  TRAFFIC  PROCESSING  CATEGORIES 


CRITICALITY 

APPLICATION  TYPE 

A. 

FLASH  OVERRIDE  (0) 

I. 

Interactive  (I/A) 

B. 

FLASH  (F) 

2. 

Query/Response  (Q/R) 

C. 

IMMEDIATE  (I) 

3. 

Bulk  1 (Bl) 

D. 

PRIORITY  (P) 

4. 

Bulk  2 (B2) 

E. 

ROUTINE  (R) 

5. 

Narrative/Record  (N/R) 

5 

[ 

t 
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TABLE  X.  PERCENTAGE  OF  TOTAL  BUSY  HOUR  TRANSACTIONS  FOR  EACH  TRAFFIC 
PROCESSING  CATEGORY 


I 

I 


TABLE  XII.  NETWORK  CONNECTION  DELAY 
CRITERIA 


CRITICALITY 

CONNECTION  DELAY 

NOT  TO  EXCEED: 

FLASH  OVERRIDE 

T <1  sec  99.99%  of  time 

FLASH 

T sec  99%  of  time 

IMMEDIATE 

T < 5sec  99%  of  time 

PRIORITY 

T<IOsec  95%  of  time 

. ROUTINE 

T<C  30sec  90%  of  time 

TABLE  XIII.  SERVICE  CONTINUITY  CRITERIA 


APPLICATION  TYPE 

PROBABILITY  OF  INTERRUPTION 
NOT  TO  EXCEED: 

Interactive 

0.1% 

Inquiry/Response 

1% 

Narrative/Record 

FLASH  OVERRIDE 

0.1% 

FLASH 

.1% 

IMMEDIATE 

1% 

PRIORITY 

5% 

ROUTINE 

10% 

Bulk  I 

1% 

Bulk  2 

1% 

r 


Communications  network  survivability  concerns  the  degree  uO  which 
communications  services  can  be  retained  or  rapidly  restored  after 
disruption  by  natural  calamity  or  by  deliberate  "enemy"  action.  The 
current  DCS  objective  for  network  survivability  is  to  design  communica- 
tions facilities  to  be  survivable  to  the  same  extent  as  the  user.  This 
planning  factor  is  couched  in  terms  of  "service"  or  "no  service"  and 
does  not  reflect  the  incremental  nature  of  service  acceptable  to  the 
user  during  varying  periods  of  emergencies.  Although  considerable  work 
has  been  done  in  identifying  critical  command  and  control  communications 
needs  and  flows  during  crisis  situations  and  a prioritization  scheme 
developed  for  selective  restoral  of  the  communications  network  on  a 
circuit-by-circuit  basis,  the  need  still  exists  to  expand  this  work  to 
the  other  subscriber  categories  as  well. 

In  the  future  development  of  the  DCS  user  requirement  data  base, 
meaningful  measure  of  "essentiality"  relating  user  needs  to  particu- 
lar emergency  situations  will  be  developed  by  DCEC  and  applied  to  each 
user  requirement.  This  will  greatly  facilitate  communications  network 
design  in  terms  of  the  communications  assets  requiring  restoral  during 
the  various  categories  of  emergency  operations. 

c.  Network  Error  Control . Errors  in  a typical  ADP  system  can  be 
generated  at  many  places  between  data  source  and  final  disposition, 
but  this  report  is  concerned  primarily  with  the  errors  generated  within 
the  communications  network,  and  the  relationship  between  communications 
error  control  and  ADP  system  error  control  design. 

A certain  number  of  errors  can  be  expected  in  data  transmitted 
through  the  communications  network.  For  most  types  of  transmission 
facilities,  statistics  are  available  giving  the  distribution  of  errors 
to  be  expected.  Depending  on  the  nature  of  the  information  transfer 
requirement  and  the  type  of  facilities  available,  the  errors  contri- 
buted by  the  network  may  either  be  insignificant  or  dominant  with  respect 
to  ADP  system  generated  errors.  Accordingly,  a major  design  tradeoff 
concerns  whether  error  control  should  be  addressed  within  the  communica- 
tions network  design,  within  the  ADP  system  design,  or  within  both. 

A discussion  of  this  question  is  clearly  beyond  the  scope  of  this  report. 
However,  it  can  be  said  that  the  decision  is  extremely  complex  and  is 
best  served,  at  least  within  today's  environment  of  limited  dialogue 
between  ADP  system  and  communications  network  planners,  by  establishing 
a single  error  rate  objective  for  the  communications  network  as  low 
as  is  commensurate  with  an  economical  network  design  while  meeting  the 
minimum  threshold  required  to  satisfy  the  majority  of  potential  users. 

With  a specific  communications  network  objective  established,  it  is 
then  left  to  the  ADP  system  designer  to  address  those  cases  where  communica 
tions  network  error  control  is  not  adequate  for  his  teleprocessing 
requirements. 
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Current  information  is  not  sufficient  to  make  any  meaningful  judg- 
ment as  to  what  error  rate  objective  will  satisfy  the  majority  of 
potential  users  in  the  1980-1985  time  frame.  Accordingly,  this  issue 
will  receive  special  attention  in  the  upcoming  IAS  studies.  It  is 
evident,  however,  that  the  minimum  allowable  error  threshold  will  have 
to  be  established  at  a figure  significantly  greater  than  the  current 
DCS  system  planning  factor  specified  as  "not  to  exceed  one  error  in 
10°  bits  for  more  than  one  percent  of  the  time." 

d.  External  System  Access.  Present  ADP  systems  are  generally 
self-contained  due  to  code  and  software  limitations.  However,  in  the 
future  ADP  systems  will  require  ever  increasing  access  to  other  ADP 
systems,  culminating  eventually  in  what  well  may  be  a national  computer 
utility.  The  communications  network  design  must  be  flexible  to  the 
shifts  in  both  traffic  pattern  and  traffic  volume  which  may  result 
from  the  associated,  dynamically  changing  communities  of  interest. 
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